The PAX Toolkit and its Applications 
at Tevatron and LHC 



in 
o 
o 

O 

Q 

m 



S3 ' 
ctf ; 

ctf ■ 
+-> • 
ctf ■ 

o ■ 

>v 

43 ■ 



> ■ 

(N ■ 

m ; 

(N . 
(N ■ 

o . 

o : 

>>: 
43 : 

Oh- 



X 



Steffen Kappler, Martin Erdmann, Ulrich Felzmann, Dominic Hirschbiihl, 
Matthias Kirsch, Giinter Quast, Alexander Schmidt and Joanna Weng 



Abstract — At the CHEP03 conference we launched the Physics 
Analysis eXpert (PAX), a C++ toolkit released for the use in 
advanced high energy physics (HEP) analyses. This toolkit allows 
to define a level of abstraction beyond detector reconstruction 
by providing a general, persistent container model for HEP 
events. Physics objects such as particles, vertices and collisions 
can easily be stored, accessed and manipulated. Bookkeeping 
of relations between these objects (like decay trees, vertex and 
collision separation, etc.) including deep copies is fully provided 
by the relation management. Event container and associated 
objects represent a uniform interface for algorithms and facilitate 
the parallel development and evaluation of different physics 
interpretations of individual events. So-called analysis factories, 
which actively identify and distinguish different physics processes 
and study systematic uncertainties, can easily be realized with the 
PAX toolkit. 

PAX is officially released to experiments at Tevatron and 
LHC. Being explored by a growing user community, it is applied 
in a number of complex physics analyses, two of which are 
presented here. We report the successful application in studies of 
tt production at the Tevatron and Higgs searches in the channel 
tiH at the LHC and give a short outlook on further developments. 

Index Terms — particle physics analysis, reconstruction of com- 
plex events, event container model, C++ toolkit; 



I. Introduction 

PHYSICS analyses at modern collider experiments enter 
a new dimension of event complexity. At the LHC, for 
instance, physics events will consist of the final state products 
of the O(20) collisions taking place during each readout 
cycle. In addition, a number of physics questions is studied 
in channels with complex event topologies and configuration 
ambiguities occurring during event analysis. 

One item in the long list of examples is a channel of t- 
quark associated Higgs production, tiH with H — > bb (see 
Fig. [^a). The event topology of four &-jets, two light-quark-jets, 
an isolated muon, missing energy and possible additional jets 
from initial state radiation (ISR) and final state radiation (FSR) 
imposes highest demands on detectors and reconstruction al- 
gorithms. In addition, non-trivial ambiguities must be resolved 
during event analysis. Even if all final state products could 
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Fig. 1 

A) Associated Higgs production in the channel tiH with H —* bb 

AND tt —i WW bb — > qq' fl&fj, bb. B) THE VISIBLE RECONSTRUCTED 
PARTONS OF THIS CHANNEL. 



be reconstructed perfectly (as illustrated in Fig.^b) and no 
ISR or FSR effects occured, at least 24 different configurations 
would be possible. Finite jet resolutions, limited efficiency and 
purity of the 6-tagging as well as the presence of additional jets 
complicate ambiguity resolution and signal identification. 

This task can be approached with a likelihood method based 
on characteristic al event variables, where each possible event 
configuration is developed individually and rated with the 
likelihood function; the most probable of all interpretations 
finally is selected. 

Such an approach can be implemented by object-oriented 
coding and suggests the use of a class collection, that provides 
event containers for the reconstructed objects (muons, jets, 
missing energy, vertices, collisions, etc.) and handles relations 
between the individual objects (as, for instance, vertex relations 
for particle decays). Due to the large number of ambiguities 
occurring during the reconstruction of tiH events, these classes 
are required to offer automated copy functionality for contain- 
ers, objects and corresponding relations. 

The application of a generalized event container comes with 
a number of desirable side-effects. If used to define an abstrac- 
tion interface between the output of event generator, simulation 
or reconstruction software and the physics analysis code, the 
latter is protected from changes in the underlying software 
packages to a large extent. This reduces code maintainance and 
increases code lucidity. In addition, unnecessary duplication 



of the analysis code can be avoided: so can the influence of 
detector effects (studied by direct comparison of the results on 
generator, simulation and on real data level) be investigated ad 
hoc, i.e. with the same analysis source code. 

Analysis factories, in which a number of analyses are ex- 
ecuted at the same runtime, identifying and distinguishing 
different physics processes or studying systematic uncertainties, 
can easily be realized when using common physics objects and 
a common event container model in each of the analyses. 

Analysis environments based on a well-defined, generalized 
event container also provide a basis for efficient team work. 
Collaboration in (and supervision of) groups of students is facil- 
itated, and knowledge transfer between subsequent generations 
of analysts as well as between different experiments is fostered. 

In this article, we present the Physics Analysis eXpert (PAX), 
a C++ toolkit for particle physics analysis that provides such 
a generalized event container together with various built-on 
functionalities. 

II. The PAX class structure 

The PAX kernel, introduced in the year 2002 [1] and released 
at the CHEP03 conference in 2003 [2], is currently available 
as 2.00 version. For the convenience of connecting to existing 
software packages, PAX is realized in the C++ programming 
language [3]. It provides additional functionality in top of the 
vector algebra of the widely-spread libraries CLHEP [4] or 
ROOT [5]. 1 The PAX container model as well as file I/O are 
based on the C++ Standard Template Library (STL) [3]. 

The PAX toolkit provides three types of generalized physics 
objects: 

• particles (or reconstructed objects), i.e. Lorentz-vectors, 
represented by the class PaxFourVector, 

• vertices, i.e. three-vectors, represented by the class PaxVer- 
tex, 

« and collisions, represented by the class PaxCollision. 
These objects are able to establish relations, and can be 
stored and managed in event containers, represented by the 
PaxEventlnterpret class. 

A. Physics objects 

The PaxFourVector class (see FigS represents particles or 
reconstructed objects (such as muons, electrons, missing en- 
ergy, jets etc.). It inherits its basic Lorentz-vector characteristics 
from the well-known libraries CLHEP or ROOT. Commonly 
needed, additional properties such as particle-id, status, charge 
etc. can be stored in data members. Specific information (such 
as b-tags, jet cone sizes or energy corrections, for instance) 
can be stored in the so-called user records. User records 
are collections of string-double pairs, meant to hold object 
information complementary to data members. 

'At compile-time, the user can choose between the vector algebra packages 
of CLHEP [4] (default) or ROOT [5]. Depending on a compiler switch, the 
two type definitions PaxLorentzVector and PaxThreeVector are set to Hep- 
LorentzVector and Hep3Vector of CLHEP or to TLorentzVector and TVector3 
of ROOT. 
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Fig. 2 

THE PaxFourVector CLASS EXTENDS THE BASIC FUNCTIONALITIES OF THE 
PaxLorentzVector IN ORDER TO REPRESENT PARTICLES IN HEP DECAYS. 



All PAX physics objects own user records (instances of the 
class PaxU serRecord) and provide methods for quick access 
to individual user record entries. Each instance of a PAX 
physics object carries an unique integer key (the so-called 
Paxld) and a string name (the so-called PaxName). An integer 
workflag facilitates tagging of individual objects. Print methods 
are provided to allow monitoring of object state and established 
relations on various verbosity levels. Copy constructors are 
provided to perform deep copies of PAX physics objects. 

The PaxVertex class, sketched in Fig.|5| represents the spatial 
point of decays in particle reactions. Thus, in analogy with the 
PaxFourVector, it obtains its basic three-vector characteristics 
also from the CLHEP or ROOT package. 

The PaxCollision class (see Fig.|4jl allows the separation of 
collisions in multicollision events, as they occur at high-rate 
hadron colliders. It provides the relation management necessary 
to associate PaxVertex and PaxFourVector objects with different 
collisions in the event. 

B. Access to primordial C++ classes 

Each PAX physics object can record pointers to an arbitrary 
number of instances of arbitrary C++ classes. This way, the 
user can keep track of the data origin within the detector 
reconstruction software, for instance. Access to the pointers 
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Fig. 3 

THE PaxVertex CLASS EXTENDS THE BASIC FUNCTIONALITIES OF THE 
PaxThreeVector IN ORDER TO REPRESENT VERTICES IN HEP PARTICLE 
DECAYS. 
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Fig. 4 

THE PaxCollision CLASS REPRESENTS COLLISIONS IN BUNCH CROSSINGS 
AT HIGH LUMINOSITY COLLIDERS. BESIDES STORAGE OF GENERAL 
PROPERTIES, THE PaxCollision ALLOWS THE USER TO ESTABLISH AND 
MANAGE RELATIONS TO PaxVertex AND PaxFourVector OBJECTS. 
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Fig. 5 

THE CLASSES PaxExperimentClass AND PaxExperiment<Type> PROVIDE 
RECORDING OF ARBITRARY POINTERS WITH PAX OBJECTS . 



is possible at the same runtime during any later stage of the 
analysis. A typical use case is the need to re-fit a track which 
requires access to the hits in the tracking chamber. The PAX 
object that represents this track, i.e. a PaxFourVector instance, 
provides the two template methods addPointer<Type>(name, 
ID, pointer) and findPointer<Type>(name, ID). The argument 
name is supposed to correspond to the C++ class name, e.g. 
Type, the argument ID is a unique integer identifier for the 
referenced instance of the C++ class Type, and the third 
argument is a pointer to this instance. 

The mechanism behind is sketched in Fig.|5] The class 
template PaxExperiment<Type> provides storage, access, and 
clone of the pointer of type Type. Its base class PaxExperi- 
mentClass is used as the interface to the PAX classes which 
are enabled to store and access the pointer through the C++ 
dynamic_cast operator. 

When copying a PAX physics object, all pointers are copied 
as well by making use of the clonef) method. 

C. Relation management 

The principal duty of the PAX relation management is 
handling of decay trees. The manager is based on the Mediator 
design pattern, described in detail in reference [6]. In this design 
all relations are kept locally (i.e. every object knows about all 
their directly related objects), so that global relation directories 
can be avoided. 

Speaking of PAX physics objects, this means, that each Pax- 
Collision object owns relation managers (see Fig.|6j that carry 
pointers to the related PaxVertex and PaxFourVector objects. 
At the same time, the PaxVertex objects hold pointers to then- 
related PaxCollision^ as well as to their incoming and outgoing 
PaxFourVector^. By the same token, PaxFourVector^ know 
about their related PaxCollision^ and about their begin and end 
PaxVertex objects. With this functionality, PAX allows to store 
complete multicollision events from parton to stable particle 
level, including four-momenta and spatial vertex information. 

In addition, the PAX relation management is used to record 
analysis histories: each object, which is copied via copy con- 
structors, keeps pointers to its original instances. This way the 
user may always go back and ask for original properties of 
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Fig. 6 

The PAX classes for relation management inherit from the 
CLASS PaxRelationManager. 
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Fig. 7 

The PAX container classes inherit from the class PaxMap. 
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Fig. 8 

THE PaxEventlnterpret CLASS REPRESENTS THE GENERALIZED CONTAINER 
FOR COMPLETE HEP EVENTS. IT STORES AND HANDLES MULTIPLE 
COLLISIONS, VERTICES AND PARTICLES AS WELL AS EVENT SPECIFIC 
INFORMATION IN THE USER RECORDS. 



objects which might have changed during the development of 
the analysis. 

A powerful feature, implemented by means of the relation 
management, is the so-called locking mechanism. It is imple- 
mented to enable the user to exclude parts of decay trees from 
the analysis (i.e. excluding a lepton from a jet finding algorithm, 
etc.). If one particle or vertex is locked, all the objects down 
the decay tree (and the history) will be locked, too. Locking 
and unlocking are relaized by setting or removing the lock-flag 
owned by each PAX physics object. 

D. Maps & object containers 

The PAX kernel provides the base classes PaxMap<key, 
item> and PaxMultiMap<key, item>, which inherit from the 
STL classes map<key, item> and multimap<key, item>, re- 
spectively. The explicit inheritance has been chosen to provide 
the use of existing STL objects and methods with these PAX 
classes. This way, iterations of PAX maps can be performed by 
using either the PAX iterator classes (Paxlterator, PaxMapIt- 
erator, PaxMultiMapIterator) or the commonly known STL 
iterators. All PAX classes which serve as containers are based 
on the class PaxMap (see Fig.0. 

E. Event container 

The PaxEventlnterpret class, illustrated in Fig.|SJ is the 
generalized event container provided by PAX. By incorporating 
the previously described functionalities, it is capable of holding 
the complete information of one multicollision event with 
decay trees, spatial vertex information, four-momenta as well 
as additional reconstruction data in the user records. Physics 
objects (i.e. instances of the classes PaxFourVector, PaxVertex 



and PaxCollision) can be added or created with the Pax- 
Eventlnterpret: :add() and PaxEventlnterpret: :create{) methods. 
Depending on the object type, a pair of Paxld and Pointer to the 
individual object is stored in one of three maps (PaxFourVec- 
torMap, PaxVertexMap or PaxCollisionMap). Access to these 
maps as well as direct access to the physics objects is guaran- 
teed via methods such as PaxEventlnterpret: :getFourVectors() 
and PaxEventlnterpret: :JindFourVector( ). At deletion of a Pax- 
Eventlnterpret instance, all contained physics objects will be 
deleted, too. 

The PaxEventlnterpret class is so named, because it is 
intended to represent a distinct interpretation of an event config- 
uration (e.g. connecting particles to the decay tree according to 
one out of a number of hypotheses, applying different jet energy 
corrections, etc.). To facilitate the development of numerous 
parallel or subsequent event interpretations, the PaxEventlnter- 
pret class features a copy constructor, which provides a deep 
copy of the event container with all data members, physics 
objects, and their (redirected) relations. 

F. PAX file I/O 

The PAX toolkit offers a file I/O scheme for persistent 
storage of the event container, based on STL streams. It allows 
the user to write the contents of PaxEventlnterpret instances 
with all contained physics objects 2 as well as their relations to 
PAX data files. When restoring the data from file, an empty 
PaxEventlnterpret instance is filled with the stored data and 
objects and all object relations are reproduced. 

2 For obvious reasons, pointers recorded with PAX physics obj ects by means 
of the PaxExperimentClass functionality (as described in section ITl-B I are not 
stored to disk. 



The PAX data file format provides multi-version and multi- 
platform compatibility. It is built of a hierarchy of binary 
data chunks: the top level unit is an event, which consists 
of an arbitrary number of event interpretations. The event 
interpretation chunk consists of data members, user records as 
well as chunks for each of the contained physics objects. Each 
chunk carries header information (one byte for unit type and 
four bytes for data amount information) and the actual binary 
data. This allows file structure checks and fast positioning. 
Therefore, the user can quickly skip arbitrary numbers of events 
in PAX data files, without having to sequentially read and 
discard. 

PAX also provides the possibility to write event units to 
strings (and to restore the PaxEventlnterpret instances from 
those strings). This way, the user can store PAX objects to 
any data format supporting strings or binary data fields (like 
databases or experiment specific data formats). 
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Fig. 9 

One possible realization of a physics analysis with PAX; a 

DEDICATED, EXPERIMENT-SPECIFIC CLASS FOR FILLING THE PAX 
CONTAINERS REPRESENTS THE INTERFACE BETWEEN DETECTOR 
RECONSTRUCTION SOFTWARE AND PAX-BASED PHYSICS ANALYSIS. THE 
PAX PERSISTENCY SCHEME IS USED TO STORE THE DATA TO PAX DATA 
FILES FOR LATER USE. 



G. Accessories and interfaces 

As a complement to the PAX kernel, we released two 
accessory packages for reading standard event generator file 
formats. The PaxTuple package provides transfilling of decay 
trees stored in the HEPEVT or ROOT Ntuple data formats 
to PaxEventlnterpret containers. Accordingly, the PaxHepMC 
package gives access to HepMC files. 

In addition, interfaces developed and posted by PAX users, 
that fill PAX objects with specific data of HEP experiments, 
are available via the PAX web page [7]. 



H. Software development procedure 

The PAX kernel and its officially supported accessories 
are coded and maintained by a core group of currently six 
developers at CERN and the Aachen and Karlsruhe universities. 
New developments and code modifications pass a certification 
procedure and are discussed and adopted in regular video 
meetings. As a guideline, new developments focus on aspects of 
performance improvement and on user feedback. New releases 
are to be backward compatible. Version management of the 
software project is handled with a web-browsable Version 
Control System (CVS) [8] [9]. 



/. Availability, documentation and support 

The continuously updated PAX web page [7] provides down- 
load of the various versions of PAX kernel and accessories 
(based on the aforementioned web-browsable CVS repository). 
It also provides the PAX Users Guide [10], a comprehensive 
text documentation of the PAX toolkit, as well as class refer- 
ence and fast navigator pages for download or online use. The 
web page also offers access to mailing lists, in which PAX users 
are informed about new developments and in which technical 
issues of PAX analyses can be discussed. 
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a) Exchangeability of the filling class allows PAX physics 

ANALYSES TO BE APPLIED TO VARIOUS INPUT SOURCES, E.G. TO MONTE 

Carlo event generator data, b) The use of PAX data files 

ALLOWS FAST ANALYSIS OF THE RECONSTRUCTION DATA DECOUPLED 
FROM THE EXPERIMENT-SPECIFIC ENVIRONMENT. 



III. HOW PAX PHYSICS ANALYSES CAN BE STRUCTURED 

To exploit the features offered by the PAX toolkit, physics 
analyses might be realized, for instance, according to the 
example structure illustrated in Fig. [9] 

There, a dedicated, experiment-specific interface class for 
filling the PAX containers (i.e. PaxEventlnterpret instances) 
represents the interface between detector reconstruction soft- 
ware and PAX-based physics analysis. Once all relevant infor- 
mation is filled, the analysis code is called, and the PAX objects 
(as obtained by the filling class or at any subsequent stage of 
the event analysis) can be stored persistently to PAX data files 
for later use. Analysis results might be further processed with 
help of the ROOT package. 

With an analysis consistently formulated with PAX objects, 
the filling class can be exchanged easily, and the identical 
analysis code can be applied, for instance, directly to the output 
of a Monte Carlo event generator or a fast simulation software, 
see Fig.^|a. Furthermore, the use of PAX data files, which 
provide the distilled experimental event information, allows 
fast analysis of the reconstruction data decoupled from the 



experiment-specific software and data storage environment, see 
Fig .[K)|b. 

IV. Implementation of PAX into experiment specific 

SOFTWARE ENVIRONMENTS 

PAX has been made available within the software environ- 
ments of the experiments CDF, DO 3 (both Tevatron) and CMS 
(LHC). 

Following the same principles, the integration of PAX into 
the latter is described as a general example. 

The PAX toolkit is provided by the CMS software environ- 
ment as an external package [11], enabling the physicists inside 
the CMS collaboration to use PAX without having to care about 
installation or setup of the package. 

An extensive example analysis for the use of PAX with the 
detector reconstruction software ORCA [12] is included in the 
CMS CVS repository [13]. In this example, the (ambiguous) 
reconstruction of the partonic process of the decay W — > pJD^ 
is carried out by using reconstructed muons and missing trans- 
verse energy. The missing information about the longitudinal 
component of the neutrino momentum is obtained with a W- 
mass constraint, which yields (up to) two analytical solutions, 
and thus two possible event interpretations. Subsequently, both 
interpretations are developed in two separate PaxEventlnterpret 
instances, and a number of example histograms is filled. 

The class design of this example analysis is based on the 
structure described in the previous section, including interface 
classes for filling PaxEventlnterpret containers with the recon- 
structed objects of ORCA. 

To facilitate the start-up for new PAX users, a tutorial video 
for this example plus supplementary material can be found in 
the CMS section of the PAX web page [14]. 

V. PAX PHYSICS ANALYSES FOR TEVATRON AND LHC 

Provided for the software environments of the CDF, DO and 
CMS experiments, PAX is being explored by a growing user 
community. In the following, two successful applications of 
PAX in complex physics analyses are presented. 

A. A PAX-based ti analysis for CDF 

In this section, an analysis of top-antitop-quark events (ti 
events) with the CDF experiment at Tevatron is described [15]. 
As illustrated in Fig.^J the electron-plus-jet decay channel 
shows similar combinatorial tasks as the aforementioned ttH 
channel. 

In this ti study, an analysis factory based on the PAX event 
interpretation concept is used to perform complete reconstruc- 
tion of the partonic scattering process and to optimize the 
separation of signal and background processes. 

The partonic process of the decay i — » Wb — > eD e b is recon- 
structed as follows. First, the W-boson decaying into electron 
and neutrino is reconstructed. From the W-mass constraint two 
possible solutions can be deduced for the longitudinal neutrino 

3 Interfaces to the DO software are available as /3- version since April 2005. 




Fig. 11 

The channel tt on parton level (a) and the visible 

RECONSTRUCTED PARTONS OF THIS CHANNEL (B). 



momentum. This results in two event interpretations for the W- 
boson. Combining each of those with one of the jets leads to 
the interpretations for the i-quark (with different kinematics and 
reconstructed masses). The remaining part of the process, i.e. 
t — > Wb — > qq'b, is reconstructed from three of the remaining 
jets. Consequently, in a four jet ti event, 24 interpretations 
can be constructed. The most likely ti event interpretation 
is selected by first demanding non-zero b-probability for one 
of the jets of one of the t-quark candidates. Finally, one of 
these solutions is selected by evaluating the most likely event 
interpretation based on kinematic properties, the reconstructed 
mass of the W boson decaying to qq', and the mass difference 
of the two reconstructed i-quarks. The resulting example plots 
are shown in Fig.1121 

B. A PAX-based tiH analysis for CMS 

The channel of associated Higgs production, tiH with H — » 
bb, by means of which the requirements to a particle physics 
analysis toolkit have been motivated in the introduction of this 
article, is studied in the CMS experiment at the LHC [18] [19], 
for instance. 

The most recent of these studies makes use of the PAX event 
interpretation concept to develop possible event interpretations 
in a manner similar to the one described in the previous CDF 
example. After development of all interpretations, a likelihood 
function is used to select the most probable one by rating the 
different configurations on the basis of kinematics variables and 
masses of the two t-quarks and their decay products. 

Fig. ^] illustrates the performance of this method in simu- 
lations with and without detector effects. Please notice, that 
Fig-El a an d Fig.^]b have been produced with the identical 
analysis code, by simply exchanging the interface classes (com- 
pare Fig.|9] and Fig. llOt . In this way, a good measure for how 
detector and reconstruction methods influence the results can 
directly be obtained - with almost no analysis code duplication. 

VI. Conclusions 

The PAX toolkit is designed to assist physicists at modern 
collider experiments in the analysis of complex scattering 



processes. PAX provides a generalized HEP event container 
with three types of physics objects (particles, vertices and 
collisions), relation management and file I/O scheme. 

The PAX event container is capable of storing the complete 
information of multicollision events (including decay trees with 
spatial vertex information, four-momenta as well as additional 
reconstruction data). An automated copy functionality for the 
event container allows the user to consistently duplicate event 
containers with physics objects and relations. The PAX file 
I/O scheme can be used to write (and read) complete event 
containers to (from) disk file; this offers an easy realization 
of distilled experiment data streams. By structuring physics 
analyses based on PAX objects, the identical source code can 
be applied to various data levels. This adds a desirable aspect 
of flexibility to the software-side of particle physics analysis. 

PAX is available within the software environments of exper- 
iments at Tevatron and LHC, where it is applied in a number 
of physics analyses. Two thereof are outlined in this article, 
demonstrating typical use cases and successful applications of 
the PAX toolkit. Evident advantages arising from the usage of 
the PAX toolkit are avoidance of code duplication, increased 
code lucidity, unified data model and nomenclature, and there- 
fore more efficient team work in the complex physics analyses 
at modern HEP experiments. 
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Fig. 12 

Verification of the 4-quark reconstruction in generated tt 
EVENTS. The full histograms show reconstructed properties of 
the event interpretation which reproduces the partonic tt state 
best. Further information results from the selection 
procedure using reconstructed quantites of the event only: 
the symbols represent the selected event interpretation, the 

dashed histogram summarizes the other possible 
interpretations. a) reconstructed mass of the t-quark with a 
subsequent leptonic w-decay. b) angular distribution of the 

vf-boson in the rest frame of the t-quark. c) angular 
distribution of the charged lepton in the rest frame of the 
W-boson. (For this study, the HERWIG Monte Carlo generator 

[16] AND CDF DETECTOR SIMULATION [17] HAVE BEEN USED.) 
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Fig. 13 

Reconstructed Higgs mass in the channel ttH with H — > 66 on 

GENERATOR (A) AND FULL SIMULATION LEVEL (B). THE GRAY SHADED 
AREA CORRESPONDS TO THE COMBINATORIAL BACKGROUND, I.E. TO 
THOSE EVENTS, IN WHICH A WRONG H — * 66 CONFIGURATION WAS 
SELECTED. (FOR THIS STUDY, THE PYTHIA MONTE CARLO GENERATOR 
[20] AND CMS DETECTOR SIMULATION [21] HAVE BEEN USED.) 



